The invention relates generally to computer systems, and deals more particularly with a technique to replace an application running on a server.
Computer servers are well known today to handle requests made via a network, such as the Internet. To access a server, a user on the Internet can type in or select a URL via the user's web browser. This request is then routed through the Internet to the address indicated by the URL. For example, if the address is “www.IBM.com/projects/subproject”, the request will first be routed to a server at address “www.IBM.com” (typically via a firewall that protects the server). The remainder of the URL, i.e. /projects/subproject, identifies the application (by name or location) that can provide the requested service. This application can reside on the server at address “www.IBM.com” or another server, in which case the server at address “www.IBM.com” serves as a proxy server. In the latter case, the server at “www.IBM.com” will route the request to the server which runs the application identified by “/projects/subproject”. When the application is invoked by the request, the application may interact with the user and provide requested information via web pages.
The following is a known example of the foregoing process. The server at “www.IBM.com” is a “proxy” server because of its role in routing requests to other servers. The proxy server at “www.IBM.com” has a table or listing of other, “working” servers and the applications they run. For example, assume the table indicates that ServerA executes the requested application “/projects/subproject”. In this example, to route the user request, the proxy server modifies the requested URL to “ServerA.IBM.com/project/subproject”, and then sends it to the working server, “ServerA”, that has access to the requested application. When ServerA receives the modified URL, it extracts the application name or location “/projects/subproject”, and passes the application identity to a middleware program within ServerA. The middleware program is an interface which runs or hosts various application(s) to which requests are made. Typically, the application will need to query a data base to obtain or build an initial web page to return to the requester. The database may be managed by a separate, “backend” server coupled to the working server. The application will then return the initial web page to the user's web browser via the middleware program and the Internet. The initial web page is generally interactive in that it includes links to other web pages to be returned by the application.
In some cases, there is only one working server that needs to run the application. In such cases, the “master” copy of the application can be stored in storage which is local and dedicated to the working server. When the working server is first activated, it reads and initializes the application from its local storage. Then, the working server creates and caches in the working server an “instance” of the application for execution in the working server. By caching and executing the instance of the application in the working server, the working server does not have to download the application from its local storage for each request. If there are other servers that need to run the application, the master copy of the application can be maintained in a shared storage.
When the application needs to be updated or replaced, the working server is shut down, and the updated or new application is installed in the dedicated storage or shared storage, as the case may be. Then, the working server is restarted and notified to read the updated or new application from dedicated storage or shared storage to make a new instance for caching and execution with the working server. The updated or new application is tested using a proxy server. This technique rendered the updated or new application unavailable for productive use for a considerable period of time.
The following technique was also known to replace or upgrade an application. A URL to a proxy server (before reformatting) to access an application “/project/subproject” was “www.IBM.com/project/subproject”. The proxy server at www.IBM.com referenced a table to determine which working server is running that application. Then, the proxy server reformatted the URL to route the request to that server. If ServerA is running that application as indicated by the table, then the proxy server reformatted the request to “ServerA.www.IBM/project/subproject”. If ServerA does not currently have an instance copy of the application in its cache, middleware within ServerA requests the application from its local storage at address “/project/subproject”. However, in this scenario, the application does not reside in ServerA's local storage Instead, the application is stored in a shared (or “distributed file” ) storage and renamed/readdressed as “/projectA/subproject” in the shared storage. Also, a symbolic link to the application in the shared storage is maintained in ServerA's local storage at address “/project/subproject” such that requests to copy the application at “/project/subproject” were redirected to “/projectA/subproject” in the shared storage. The following is the known technique to update or replace the application in this scenario. The updated or new application was written into a different location in the shared storage, and a new, test server was set up. The updated or new application in the shared storage was named “/projectB/subproject”. The test server was configured to request the application “/project/subproject” from its local storage, and a symbolic link was written into the local storage of the test server to redirect the request to application “/projectB/subproject” from the shared storage. After receiving a copy of the updated or new application, the test server created and cached an instance of the application for testing. A “dummy” proxy server was connected between the test server and the Internet, and an operator sent requests via the Internet and proxy server to the test server for application “/project/subproject”. In the foregoing example, the web browser requests would have a URL “www.xyz.com/project/subproject”, where the URL of the test server is “www.xyz.com”. Then, the operator determined how well the test server with its application instance “/projectB/subproject” handled the requests. After the tests were successfully completed, the operator changed a configuration file in the original proxy server to direct “www.IBM.com/project/subproject” requests to the test server. Thus, the test server with its application instance “/projectB/subproject” became the new working server, replacing the original working server with its application “/projectA/subproject”. This change to the configuration file took only a few minutes, so there was little down time for the application.
In the foregoing example, in the shared storage, the name of the application requested by the working server and the test server from their respective local storages differed from the names of the applications in shared storage by a change to the first level qualifier, “/project” versus “/projectA”, and “project” versus “/projectB”. While the foregoing technique caused much less down time of the application than the earlier technique, it required that the working server and test server (which ultimately became the working server) only run one application each, i.e. “/projectA/subproject” in the working server and “/projectB/subproject” in the test server (which ultimately became the replacement working server). This is because the first level qualifier of the name of each application in shared storage was directed to a specific application, and not a hierarchical group of applications, and certain middleware programs such as IBM WebSphere and IBM HTTP Server (IHS) programs can only reference applications with the same first level qualifier (or “context root”). In this example, there was only one application associated with this first level qualifier, so each server could only run one application. (These types of middleware programs use “relative pathing” which are paths that branch from the directory containing the current document. The paths or directory have no absolute beginning because it is assumed that they start in the current directory of the script/document using the path. In other words, the top node in the hierarchy such as “www.ibm.com” is assumed and does not have to included in the specification of the path). Because of the “relative pathing” feature, these types of middle ware programs are limited to one context route.) For many environments, it is desirable to allow one server with one middleware program of the foregoing type to run multiple applications.
Accordingly, an object of the present invention is to facilitate the use and installation of an updated or new application in a server which also runs other applications using the same middleware program.
Another object of the present invention is to facilitate the use and installation of an updated or new application in a server having a middleware program which is limited to one context route, but would like to run other applications as well.